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The  use  of  IDEF  is  mandated  by  the  DDI  (DoD's  Director  of  Defense  Information)  for 
definitioD  of  all  Business  Case  and  Functional  Economic  Analyses  (BCA/FEA).  This  brief 
p^)er  reviews  the  IDEF  methodology  and  considers  aspects  of  its  use,  both  its  advantages  and 
disadvantages. 


1.  Introduglign 

The  use  of  the  IDEF  (a  system  detinition  methodology)  is  required  by  the  DDI  in  docunxnting  parts  of  required 
FEA  (Functional  Economic  Analysis).  This  metbo^logy  doives,  in  its  present  form,  from  the  Integrated 
Conq)Uter'Aided  Manufacturing  (ICAM)  program,  where  a  specitication  standard  methodology  was  need^  for 
manufacturing  data  q)ecificati(m  and  interchange;  a  funily  of  tools  is  available  to  aid  the  IDEF  process.  IDEF 
stands  for  ICAM  dkinition. 

A  very  brief  review  of  the  FEA  process  is  given  first.  Then,  because  there  have  been  questions  about  the  use  of 
IDEF  venus  certain  oth«  metho^Iogies  and  automated  tools,  we  attenqrt  to  answer  the  following  questions: 

*  What  is  the  IDEF  methodology? 

«  What  is  the  rdative  value  of  such  a  methodology  and  what  are  the  tools  currently  available  to  siqiport 
them. 

«  What  is  die  difference  between  IDEF  and  die  many  Information  Systems  methodologies  and  their 

aupporting  CASE  (Conqniter  Aided  System  Engineering)  tools?  | 


The  toms  Business  Case  Analysis  (BCA)  and  FEA  are  often  used  interchangeably.  Here  we  attenqit  to  i 
distinguish  them  with  the  following  deftnitions.  ^1 

A  BCA  is  the  process  of  modeling  and  analyzing  the  business  activities  of  an  organization  and  iti 
atqipoiting  infrastructure.  ^ 
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Obviously,  not  the  leist  problm  in  «  BCA  is  in  determining  the  scope  or  oontour  of  die  business  being 

■nslyzed:  Does  it  tocotapus  all  business  or  only  certain  parti?  Ohm  a  set  of  specific  units  or  offices  have  been 
identified,  this  is  further  refined  into  tibe  questions: 

•  What  interactions  are  dime  between  diis  portion  of  die  business  and  odiert?  and 

•  How  can  die  parts  be  isolated  so  diat  die  boundaries  are  not  en«fti«in£  to  die  analysts  and  the  allocatioo 
of  the  savings  is  not  diqmted  by  the  various  business  areas? 

FEA  is  more  qiedfic  to  DoD  opetadoos. 

An  FEA  deals  with  die  business  aiudyns  of  DoD  defined  functional  areas  (diose  under  die  control  of  a 
Functional  Manager),  using  them  as  a  dqierture  punt  for  an  initial  cut  at  acoping  die  area  or  unit  under 
consideratiaiL 

The  overall  FEA  process  involves  several  stqis: 

1.  Create  an  initial  Business  Process  Model.  An  initial  business  process  modd  is  created  by  interviews 
or  having  users  and  functional  area  managers  participate  in  a  fiidlitated  business  process  modeling 
workshop.  Then  baseline  business  process  model  is  created  with  the  help  of  functional  area  users, 
managers,  qrstems  analysts,  cost  analysts,  and  other  expmts.  A  pictorial  process  modd  is  devdoped  to 
help  visualize  the  results  and  understand  the  analysis. 

2.  Determine  Activity-Based  Performance  and  Cost  Data.  Cost  and  performance  data  is  determined  for 
die  initial  process  modd  and  used  a  baseline.  A  high-levd  data  modd  for  the  functional  area  may  also 
be  developed  at  diia  stage. 

3.  Devdop  Alternative  Business  Process  Modds.  The  project  team  evaluates  die  baseline  business  process 
modd  to  identify  opportunities  for  streamlining  and  redesigning  processes.  A  aet  of  criteria,  such  as 
generalized  coupling  and  cdiesion,  is  developed  in  evduating  dtematives. 

4.  Evaluate  Alternative  Business  Process  Models.  Altmnative  business  process  "xyt^tc  are  evduated 
based  on  cost  and  performance  data,  such  as  die  investments  conpared  with  the  baseline.  Poformance 
data,  such  as  volume  and  frequency  of  inputs  and  outputs  as  well  as  response  time  of  processes  is  used  to 
build  a  simulation  model  to  analyze  the  dynamic  behavior  of  the  dtematives.  Cosu  are  also  derived. 

5.  IVeseat  and  Select  One  of  the  Alternatives.  A  find  set  of  dtematives  is  presented  to  top  management, 
a  recommended  dtemative  is  identified.  Top  management  will  select  one  dtemative. 

The  term  'system*  as  used  in  the  field  of  modding  generally  implies: 

a  relatively  large  conplex  of  interconnected  parts  with  an  organized  amy  of  individuals  forming  and 
working  as  a  unit. 

The  criteria  for  choosing  a  system  modeling  methodology  is  primarily  that  it  be  apprtqiriate  for  modeling  the  type 
of  system  under  consideration.  It  must  also  be: 

•  Easy  to  learn  and  use  by  its  intended  users. 

•  Capture  information  of  the  target  system  in  a  structured  way  so  tiiat  die  information  can  be  further 
andyzed,  preferably  by  conqiuter  programs. 

•  Support  decomposition  of  die  system  into  a  hierarchicd  organization  (e.g.,  a  deconpodtion)  of 
oonponents  with  different  level  of  abstraction. 

3.  The  roEF  Family  of  System  Pesipi  Methodologies 

The  first  of  die  IDEF  methodologies  was  called  IDEF,.  This  is  a  functiood  modeling  mediod,  somewhat  rimilT 
to  a  coaveationd  procedurd  and  control  flow  chart  with  aspects  of  a  genod  data  flow  diagram.  A  second  subset 
(IDEF,)  is  based  on  Chen's  Entity-Relationdiip-Attribute  tnodd  for  oooceptud  data  base  design.  IDEF,  Extended 
(IDEF,,)  was  devdoped  under  die  Integrated  Information  Support  System  (OSS)  project,  under  die  ICAM 
Program,  as  a  data  inodeling  technique  to  describe  common  data  model  subsystmn.  The  primary  contractor  is 
Generd  Electric  Conpany.  The  find  rqwrt  was  delivered  in  November  19M.  This  has  since  been  extended, 
mainly  by  D.  Appleton  Conpany  (DACOM).  Other  membm  of  the  IDEF  fiunily  include  a  simulation  language 
(IDEF,)  devdoped  mainly  by  Pritsker  Sc  Associates.  It  can  be  used  to  simulate  a  design,  diereby  representing 


Dfnc  Qu  alut  hjcpectbd  l 


Disl  1  cv..,. 

i  I 


time  vaiying  bdiavior  of  leaources  in  n  qrsteoL  There  is  an  on-going  effort  to  extend  die  IDEF  niite  of  methods 
[Mayer  and  Painter,  1991],  as  summarized  in  Table  1.  Odier  menibers  of  die  IDEF  funily  (IDEF7  to  IDEF14)  are 
in  review  by  die  IDEF  Users  Group.  In  diis  report,  the  discosaon  is  focused  on  IDEF,  and  IDEF^  and  their 
qiplicatioos  in  BCA/FEA. 


IDEF  Method 

Description 

Docmneiit  or  Status 

IDEF, 

Functional  modeling  method  derived  from  SADT. 

ICAM  program  rqiort,  1981. 

IDEF, 

Information  modeling  method  derived  from  Peter 
Chen's,  Entity-Relationship  model. 

ICAM  program  rqiort,  1981. 

IDEF,. 

Data  modeling  method  diat  siqiport  logical  design  of 
relatioiud  databases. 

ICAM  Project  rqwrt,  1985. 

IDEF, 

Dyiumic  modeling  method  for  describing  time  varying 
b^vior  of  functions  and  information. 

ICAM  Program  report,  1981. 

IDEF, 

Process  flow  and  object  state  description  mediod  that 
uses  a  sceiurio  driven  process  to  cipture  domain 
expert  knowledge  about  the  behavior  of  a  qrstem. 

Emerging 

IDEF. 

Otgect-oriented  design  method  to  assist  design  of  a 
system  inplemented  in  object-oriented  technology. 

Emerging 

IDEF, 

ConcqH/Ontolqgy  description  method  used  for 
knowledge  acquintion  in  building  knowledge-based 
gysteau 

Emerging 

IDEF, 

A  method  that  facilitates  acquisition,  representation, 
and  manipulation  of  design  rationale  of  a  system. 

Still  in  a  formative  stage 

Table  1.  A  Summary  of  die  IDEF  Suite  of  Methods 

A  model  is  expected  to  answer  questions  about  die  requirements  and  initul  design  decisions  of  a  system.  It 
should  have  a  clearly  defined  boundary,  a  viewpoint,  and  a  porpoae. 

Data  is  die  foundation  of  modem  infonnatioo  systems  enabled  by  data  base  technologies  and  it  diould  be  imuiaged 
as  a  corporate-wide  resource.  The  basic  assunqition  of  data  modeling  is  that  data  in  an  organization  exist  and  can 
be  described  independendy  of  how  these  data  are  used.  The  types  of  data  used  in  an  organization  do  not  diange 
very  much  and  t^  have  certain  inherent  properties  which  1^  to  correct  structuring  of  a  data  model  which 
serves  as  a  foundation  for  die  development  of  an  enterprise-wide/function-qiecific  database  system.  A  well- 
designed  data  model  should  be  a  stable  one.  A  data  modeling  technique  used  in  die  BCA/FEA  process  diould  be 
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■  oooceptual  dit«  modeling  tedmique  «Udi  uses  t  mitiimutn  nt  of  grqihical  notndoiu  to  wappott  die  dedgn  of 
eodHieer  oriented  dit«  modds. 


An  entity  is  •  due  of  dgects  or  events,  nsl  or  dxtnct,  sbout  triiidi  we  store  data.  It  represents  a  set  of  entity 
instances  sriiidi  can  be  described  die  same  set  of  attributes.  The  attribute  value  of  die  same  attribute  for  each 
entity  instance  may  be  difleicnL  The  name  of  eadi  entity  is  a  noun  or  an  adjective  and  a  noun  in  die  sinfular 
form.  Exanqiles  of  entities  are  product,  eiqiloyee,  project,  departmenL 


3. 1  The  IDEFq  Diagram 


Activities  and  diings  are  two  object  types  diat  can  be  modded  in  IDEF,.  Activities  are  fonctions  and  processes 
perfoimed  hy  die  qratem.  Things  include  bodi  data  (e.f.,  a  Uueprint,  customer  orders)  and  non-data  olgects 
(e.f.,  parts,  machine  tools,  an  automated  system).  The  mteractioos  between  diings  and  activities  are  called 
connections.  IDEF,  diagrams  have  boxes  and  arrows.  Boxes  represent  activities  and  have  dominanoe.  Arrows 
repreeeat  diinp  diat  interact  with  activities  diqr  are  interconnections  between  boxes.  Arrows  boxes 

together  to  indicate  constraints  or  dominanoes  of  one  activity  on  anther. 


A IDEF,  diagram  dso  contains  die  following  information: 

•  Title 

•  Author(s)  of  die  diagram 

-•  Project  Name 

•  Date  of  creation 


Date  of  last  revisioo 

Diagram  status:  Working,  Draft,  Recommend,  or  Publication 
A  list  of  readers  and  dates  wiien  read. 


Context:  Position  of  the  diagram  in  die  parent  diagram,  e.g..  None  for  AO  diagram.  Top  for  first-level 

to  diow  die  relative  position  of  the  parent  process  in  die 


decorrqioadon  diagram,  or  , 


decorrqxisition  diagram  to  wbidi  it  belongs. 

Node  Number  A  unique  identifier  of  a  box.  It  consisU  of  project  abbreviation,  */*,  Node  index  number 
of  the  parent  node,  and  box  number  of  die  node  in  die  diagram.  For  exairqiles:  FEA/Al,  FEA/A13, 
FEA/A32. 


Notes:  Substantive  comments  about  die  diagram 

C-Number  An  IDEF,  diagram'  unique  identifier  (e.g.,  MC  002).  It  consisU  of  the  author's  initials  (or 
unique  identifier)  and  a  aequence  nuniber.  The  C-number  of  a  previous  version  of  the  diagram  is 
enclosed  in  parentheses  to  provide  link  to  prior  work. 


A  system  can  be  modeled  as  an  set  of  interrelated  IDEF,  diagrams,  texU,  and  glossary.  Diagrams  are  the  mqjor 
conqioneoU  of  die  model.  The  highest-Ievd  diagram,  called  AO,  itpreseoU  the  whole  system.  An  AO  diagram 
has  only  one  box  and  is  annotated  by  PURPOSE  and  VIEWPOINT.  Ihe  PURPOSE  is  to  answer  questioos  about 
the  system;  c.g.,  die  reaaon  why  die  modd  wu  devdoped.  A  qrstem  can  be  described  from  several 
VIEWPOINTS  (i.e.,  diat  of  a  person  or  an  organizatiooal  unit).  An  IDEF,  diould,  however,  be  developed  from 
only  one  partici^  viewpoint 


The  role  of  die  arrows  is  inqiortant  in  IDEF,  diagrams: 

•  Arrows  represent  how  boxes  influenoe  or  constrain  aach  odier.  A  box  can  nyd  iu  ouqiut  to  anodier 
functioo  for  further  transformatioo  or  provide  a  control  that  govarn  what  another  function  perform. 

•  The  side  of  the  box  at  whidi  an  arrow  enters  or  leaves  determine  die  role  of  an  arrow  0.e.,  a  thing) 

related  to  die  box.  Tbeae  roles  include  input  (left),  control  (top),  output  (ri^),  and  (bottom) 

They  are  referred  to  as  ICOM  in  IDEF,  diagraim, 

•  Arrow  branches  1  may  be  one  of  two  types.  Brandies  diat  are  not  labded  are  to 

contain  all  die  things  carried  by  die  arrow  before  die  branch.  If  diey  are  labded,  they  could  contain 


fooe  or  all  of  die  duop  carried  by  die  arrow  before  (he  bnadi. 

•  Arrow  joiiu  ^  are  aiinilarly  of  two  (ypea.  Bnacliea  dial  are  not  labeled  are  aarninfid  to  oootain 

all  die  duflfs  carried  Iqr  (he  arrow  after  (he  join.  Brancbea  diat  are  labeled  ooold  oootain  aome  or  all  of 
die  diinfs  carried  Iqr  die  arrow  after  die  join. 

A  genetic  IDEF,  diagram  in  Figure  1  can  be  deacribed  ar 


Control 


Figure  1.  The  Basic  Constructs  of  IDEF,  Diagrams 


^jgut^r^us^med^jl^^^Rafo^ntoos^u^ttcordin^^DMjnDls^^ani^ei^nniin^ 


Inputs 


transfomied  by  the  function  into  ou^wts. 


deacribe  resources  or  data  diat  are  needed  to  perform  die  function  and  are 


Controls  I - 1  describe  the  conditions,  rules,  procedures,  or  drcumstaoces  diat  govern  (he  execution 

of  die  function.  An  arrow  is  a  control  unless  it  obviously  serves  as  iiqiut.  Each  function  tibould  have  at 
least  one  control  arrow.  Most  controls  ate  in  the  form  of  data. 


Outputs  I  I  are  die  data  or  non-dats  objects  that  are  transformed  by  die  process  and  leave  its 

boundary.  An  ou^  of  one  process  can  be  used  as  inputs,  controls,  or  of  anodier. 

?  . 

Mechanisms  define  die  acton  (i.e.,  siqiportiag  mechanisme)  diat  cany  out  die  function.  A 

mechanism  may  be  a  person,  an  organizational  unit,  a  physical  device,  a  computer  program,  etc. 


IDEF,  tequires  3  to  6  boxes  in  any  one  diagram  except  the  AO  diagram.  IDEF,  tends  to  be  used  as  a  physical 
model  because  it  can  describe  die  implemeotation  mectumtsm  of  qrsteov  functkms.  However,  IDEF,  can  be 
nsed  to  provide  a  logical  (i.e.,  easrntisl)  model  of  die  systeoL  can  be  used  to  show  matoial  flows.  The 

definition  of  control  in  IDEF,  is  much  broader  dian  die  control  flow  and  control  process  used  in  real-time  Data 
Flow  Diagram. 
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3.2  The  IDEFj  Diagram 

An  eotity  ctn  be  deecribed  by  its  nsnie,  descripdoo,  •  set  of  attributes.  IVo  types  of  entities  may  be  lepreseoted 
in  IDEF,,  hy  difTeraitly  siu^ied  boxes:  iiatt\fier4itdependeia  and  ideni^ier-dq>endeiu  entities.  An 
ideotifier<4Ddq>endeDt  entity  diown  in  FifW«  2(a)  is  also  calM  an  indepeodent  entity.  Each  instance  of  the 
indq>eodent  entity  can  be  aniqnely  identified  widi^  die  existence  of  any  lelationships  widi  other  entities.  An 
identifier-dependeot  entity  is  shown  in  Fifure  2(b);  it  is  also  tanned  a  dependent  entity.  The  existence  and  unique 
identification  of  each  of  a  dependent  entity  depend  on  die  exiatesire  of  its  relationship  to  anodier  entity. 

Entity  Name  Entity  Name 

I  '  ~  —i  *  —  \ 


■  ■  V  -  ■  -M  ~  J 

(a)  (b) 

Figure  2  Two  Types  of  Entities 

A  relstiooship  it  to  asaodttioa  amonf  entity  types.  In  IDEF,,  a  telationdup  typically  bvolves  two  enddes  (i.e., 
a  binary  relationship)  or  one  endty  (unary  or  recursive  reladonship).  A  reladonship  involved  more  than  two 
endty  types  Cut.,  N-ary  reladonship)  can  be  rqireseoted  using  an  asaociadve  endty.  Associadve  enddes  are  not 
expliddy  defined  in  IDEF,,. 

An  eadty-leTel  IDEF^  diagram  di^lays  endty  names  and/or  reladonship  names.  Many  to  many  reladonships  are 
allowed.  An  exanqile  of  endty-Ievd  IDEF,.  is  diowB  in  Figure  3. 


Customer  Order 

I  - - «l  1 


Figures.  Endty-level IDEF,, Diagram 

A  IftjAtnd  IDEF,,  diagram  dityilays  die  endty  names  as  well  as  the  primary  keys  of  die  enddes  in  the  diagram  as 
depicted  in  Figure  3.  Non-Specific  reladonships  diould  be  resolved  into  two  qiecific  connecdoo  reladonships. 


Cuatomnr  Ordnr _ 

I  CMstomar  ID  |»—  — — nrdnrnmnbnr^ 


Figured.  Key-levd IDEF^ Diagram 


An  attribute-levd  IDEF,,  diagram  displays  die  endty  names,  the  primary  fcqrs  and  all  die  non-key  attributes  of 
the  enddes  in  the  diagram  as  dqiicted  in  Figure  5. 
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Customer _ 

customer  ID 

customer  name 
customer  address 
customer  phone  number 


Order 


places 


order  number 


customer  ID  (FK) 
order  dale 


Fi|imS.  Attribta^4evel  IDEF^  Disfitm 

A  ^wdfic  ooonectioa  felatknihip  if  alfo  called  a  ooaoectiao  telatioiuhip.,  which  if  depicted  af  a  line  drawn 
between  die  parent  entity  and  die  child  entity  fndi  a  dot  at  the  child  end  of  die  line.  Cardinality  of  die 
connection  reladouhip  if  frequendy  termed  a  busineac  rule,  becauae  it  iiqilies  certain  business  ptdides  and  rules. 
For  example,  ”a  manager  can  only  manage  one  and  only  one  organizadoo  unit.”  The  default  child  cardinality  is  0 
to  0,  1,  or  many.  A  letter/nuniber  syinbol  is  used  to  repreaent  the  cardinality  of  die  child  entity  associated  with 
die  relationship. 

Specific  connection  relationslups  can  be  clasafied  as:  identifying  and  non-identifying  relationdups.  In  an 
i^tifying  relationship  the  parent  entity  is  used  as  part  of  die  primary  of  the  child  entity.  The  child  entity  is 
always  an  identifier-dqiendent  entity.  The  parent  entity  will  be  an  idcntifierMiidependent  entity  unless  the  parent 
entity  is  a  child  entity  of  some  other  identifying  relationship.  In  a  non-identifying  relationdiip,  the  primary  key 
of  parent  entity  is  an  non-key  attribute  of  its  child  entity. 

A  noo-qiecific  connectioo  relatioodiip  represents  a  many-to-many  relationship  between  two  entities.  It  is 
represented  u  a  aolid  line  between  two  entities  widi  a  black  dot  connects  to  each  of  the  entity  as  depicted  in 
Figures. 


Student 

- k 


Takes/ls-talcer>-by 


Course 


Figured.  Non-qiecific Relationdiip 

Categorization  Relationship  siqiport  die  geoeralizstion/qiecializBtioo  concept  in  data  modeling.  A  categorization 
entity  is  a  collection  of  entities  of  die  same  fype  to  which  a  narrower  definition  and  additional  attributes  and 
relationships  ^ly.  A  categoriuaion  entity  irdietits  (as  in  an  olgect  oriented  ^roadi)  all  the  attributes  and 
lelationshipe  of  its  parent  entity  type  (called  a  generic  entity).  An  attribute  wboae  values  partition  die  generic 
entities  into  categorization  entities  is  called  a  category  discriminator.  If  eadi  inttsiyiit  of  die  generic  entity  can  be 
classified  into  one  of  the  categorization  entities,  die  categorizstion  relationship  is  called  complete  ca^goiization 
relationship.  If  some  instances  of  the  generic  entity  cannot  be  classified  into  existing  categorization  entities,  die 
categtmzation  relationsfaip  is  called  incomplete  categorization  relationship. 

Attribute  describe  entities,  but  not  relationdiipe.  Attributes  for  entities  are  underlined  in  fidlowing  exaiqiles: 

•  Product  has  guantitv-owAsnd.  wrijdit.  volume,  color,  and  name. 

•  Enqiloyee  has  SSN.  aalarv.  and  birthday. 

An  alternative  key  is  a  unique  identifier.  It  can  be  a  simple  attribute  or  a  composite  attribute  used  to  identify  an 
instance  of  an  entity.  For  example,  EMPLOYEE  may  have  two  candidate  keys:  Employee  ID  and  SSN 
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A  Secondary  (Indexed)  Key  if  •  key  diet  hu  beeo  need  by  the  tmderiyinf  DBMS  to  cnate  indexes  for  fut 
letiievtl.  A  Concatenated  (Combing)  JCcy  is  a  kqr  that  coosisU  of  •  more  than  one  attributes.  AFordgnKeyis 
m  attribute  (a  Daa<key  attribute  or  an  attribute  diat  is  part  of  die  primary  )Dty)  in  a  relarioa,  that  has  beeo  used  as 
a  primary  kr^  in  another  rdadoo.  U  it  thoaHeAelMing  field. 

An  Aaaociative  Eadly  Type  is  an  Entity  Type  whose  existence  is  meaninfful  only  if  it  participates  in  several 
(>■■2)  Rdatwoihip  Typm  at  die  same  time.  Aaoodative  Entity  Types  are  ofteo  introduced  to  represent 
additioiul  infonnatioo  in  many-io-tnaity  Relatioodiips  or  to  decompose  a  maity-eo-maity  Relatioodiip  into  two 
one-io-many  Rdationships.  Associated  Entity  Types  are  also  need  to  represent  n-ory  (e>  »3)  Relatioodiips  in  a 
binary  data  modal. 


4.  Availabaity  of  mEF  and  BCA/FEA  Support  Tools 

There  are  several  tods  diat  could  be  used  to  si^poit  the  qiplicatiao  of  IDEF  and  BCA/FEA.  Many  techniques 
and  methods  used  in  an  FEA  study  are  conqilex  and  a  large  amount  of  atructured  information  is  generated  in  the 
defiiutioo  process.  Selecting  appropriate  tools  and  integrating  them  to  support  the  techniques  and  methods  is 
critical  to  the  successful  inqilemeotation  of  an  FEA. 


4.1  Computer-Aided  Diagramming  Tools  for  IDEF ^  and  IDEF 


Currendy  there  are  several  COTS  dut  siqiport  IDEF,  and  IDEF^.  Some  basic  information  of  these  IDEF  tools 
are  listed  in  Table  2. 


noduct  Name 

Mctbodolofy  supported 

Vendor  Name 

Hardware 

IDEFine-O,  IDEHne-lx 

roEF^ 

Wizdom  Systems,  Inc 

Sun,  PC,  Apollo,  VAX 

andlDEFoost 

IDEF^ 

Design/IDEF 

IDEF, 

Meta  Software  Corp. 

Mac,  PC,  Unix 
woricstatioo 

IDEF/Lcrerage 

IDEF, 

D.  Appleton  Company 

PC,  VAX,  microVAX 

IDEF„ 

AIOAAUx 

IDEF, 

IDEF^ 

Knowledlge  Based 
Systems,  Inc 

PC,  LAN 

Authonnate 

IDEF, 

Edcdk  Solutions 

PC,  VAX 

ERWin 

IDEF„ 

Logic  Works 

MS  Wbdows 

TaUe2.  IDEF  Took  for  IDEFO  and  1 


There  are  aeveral  ^iproeches  diat  DISA  can  take  in  providing  computer-aided  diagramming  tools  to  support  the 
use  of  IDEF  techniques.  All  of  these  may  be  viable  dtemativsa. 

1.  Select  the  best  tool  from  the  marke^leoe  and  make  it  a  standard  tool. 

2.  Recommend  a  list  of  totds  dial  siqiport  existing  IDEF  methods  specified  in  the  ICAM  program. 


t 


3. 


Recomincod  uie  of  a  CASE  thell  to  iCDerato  diifrusming  tools  that  mqjpoit  IDEF  to  meet  the  specific 
requiremeats  in  q>plyinf  IDEF  for  FEA. 


One  advanta(e  of  foe  Utter  altenative  it  foat  CASE  foellt  provide  a  flexible  approadi  to  nqipotting  existing  and 
future  mefoodt  required  in  foe  BCA/FEA  process.  CASE  shells  are  software  tools  foat  alkw  users  to  define  a 
syttetn  mndelin^  inefoodolofy  and  then  fenerate  a  fun*tiine  envimuneot  to  siqiport  foe  spedficatioo  of  a  tsrfet 
qrstMD  usinf  foe  inefood<dofy.  There  are  several  commercially  available  CASE  diells  in  ^  markeq>laoe.  It  «rill 
be  a  worthwhile  effort  for  OM  to  evaluate  foeae  CASE  foeUs.  The  beaeEtt  of  foe  CASE  shell  U  that,  it  allows 
foe  customi ration  and  evolution  of  foe  methodology.  Existing  IDEF  tooU  might  need  appropriate  exiensioot  to 
aiq>port  foe  modeling  and  analysis.  Using  a  CASE  foell  to  generate  tooU  to  stqjport  ID^  will  allow  continuous 
uxqprovement  of  IDEF  and  smooth  integratioo  of  IDEF  with  tooU  needed  in  foe  BCA/FEA  and  in  foe  downstream 
systems  development  process.  Examples  of  audi  CASE  ahdU  are:  ProtoSoft’s  Paradigm  Plus  CASE 
Development  Kit,  Interaolv's  XL/Customizer,  Systematica's  Virtual  Software  Factory,  CADWare's  Sylvu 
Foundry,  etc.  However,  foe  Graphics  User  Interface  in  many  of  foeee  tooU  U  still  primitive. 

The  wmfc  of  certain  standards  committors,  sudi  as  foe  IDEF  Users  Group  and  the  Electtonic  Industries 
Associate's  CDIF  (CASE  Data  Interchange  Format)  Committor  may  soon  make  it  possible  to  pass  designs  from 
one  vendor's  tool  to  another. 


4.2  Tools  That  Support  the  BCA/FEA 

There  are  several  other  types  of  tooU  foat  could  siq>port  foe  BCA/FEA  process.  Using  IDEF  for  bunneas  process 
modeling  under  foe  contutt  of  BCA/FEA  is  a  collaborative  effort  among  functional  area  usm,  managers,  cost 
analysts,  informatioo  engineers,  and  businesa  engineers.  It  is  a  change  process  because  foe  iwengineering 
business  procea  may  dramatically  change  how  work  will  be  done  m  foe  future.  Team^ented  techniques,  such 
as  Joint  Application  Design  may  be  used  to  encourage  proper  participation  of  all  parties  involved  in  foe  process  to 
ensure  all  foe  requirements  and  concerns  are  surfued  and  addressed.  One  of  foe  critical  success  Uctots  in  using 
JAD  u  foe  doll  of  foe  facilitator  (i.e.,  sessioo  leader).  However,  aidUful  fitoiliutors  are  hard  to  find.  Emerging 
colUboration  technologies  can  be  used  to  assist  UcUitate  business  process  modeling  workshop.  CoUaboration 
technology  can  be  used  to  provide  anonymity,  equal  participation,  and  complete  documentation  of  workshop 
outcomes.  It  is  not  going  to  rq>Uoe  a  good  Ucilitator,  but  it  can  be  used  to  improve  foe  effectiveness  of  business 
process  modeling. 

Conducting  BCA/FEA  U  a  very  political  process.  Group  ficilitation  techniques  and  collaboration  technologies 
can  be  used  to  assist  to  siqiport  businm  procea  modeling  meetings.  Groiq>  wappott  systems,  sudi  m 
GroupSystems  and  VisionC^u^  can  be  used  u  a  froot>«od  requiretnenu  elicitatioo  t^  foal  capture  initial 
^ecifications  of  a  businea  procea  [Chen  and  Nunamaker,  1991).  These  qwcificatiou  can  be  trimsferred  to 
IDEF  tools  for  foe  construction  of  formal  IDEF  models.  We  have  developed  a  CoUaboration  Technology 
Laboratory  at  George  Mason  University,  foat  can  be  used  to  demoustrate  this  approach. 

The  IDA  Template  can  also  be  used  to  present  foe  final  cost  analysis  of  various  alternative  businea  procea 
models  with  foe  baseline  model.  Cost  data  collected  for  various  alternativa  and  for  foe  baseline  can  be  presented 
in  different  formats  (e.g.,  gr^)hics  and  tabla)  based  on  a  qiecific  cost  breakdown  structure.  The  two  mijor  cost 
items  are:  Operations  Costs  and  Management  &  Support  Cost.  Each  of  foem  is  broken  down  mto  foe  nwjor  life 
cycle  phases  and  expense  types.  Cost  dau  of  foe  baseline  and  alternativa  are  entered  into  a  cost  Data  Sheet  based 
on  ride  and  foe  detailed  cost  breakdown  structure  over  a  six>ysar  period.  For  alternativa,  eadi  cost 

item  hu  foe  high  and  low  valua.  It  it  a  way  to  exprea  foe  risk  or  uncertainty  invdvad  in  foe  estimation.  An 
analysis  is  performed  on  each  alternative.  The  results  are  presented  in  gnphia  and  taUa. 


5.  Compariaon  of  mEF  Methodology  with  Dataflow.  ERA,  ind  Other  Tcchniquei 


A  system  can  be  modeled  from  miltiple  viewpoints.  However,  IDEF,  only  aUows  a  user  to  model  a  system  from 


a  luijle  viewpoint  A  qratem  model  ooosiau  of  a  aet  of  interrelated  diafnuna,  texts,  and  tables.  Dataflow 
diaframi  (DFD)  can  be  to  deacribe  both  die  lofical  and  physica]  aspect  of  an  exiadnt  (AS>1S)  aystetn  or  a 
•Bw  (TO-BE)  ayatem.  juat  as  can  IDEF^  When  a  DFD  is  used  to  specify  the  physical  aapoet  of  a  system,  the 
implementatioo  mechanisms  can  be  amended  to  die  processes,  data  flo^,  and  data  stores  in  the  disfram. 
Mechanism  can  also  be  cultured  m  the  corre^ioadinf  antiy  of  an  object  in  the  rqiOBitory.  Coofi|uratioa 
management  accessories  in  many  CASE  tool  environments  today  should  substantially  aid  in  relieving  the  problems 
noted  above. 

Real-time  Data  Flow  Diagramming  (DFD)  Technique  can  be  used  to  achieve  die  aame  repreeentatioa  power  as 
IDEF^  The  real-time  vcreiona  of  DFDs  can  be  ua^  to  represent  data  flow  to  represent  inputs  and  ouqwts  of  a 
proceaa.  Control  flow  has  been  amended  m  the  real-time  DFD  to  represent  signals  that  ecuble  and  diWble  data 
processes.  Control  proccaees  are  used  to  coordinate  the  execution  of  data  processes.  Control  processes  can  then 
be  augmented  by  State-Transitioa  Diagram  (STD)  or  Petri  Net  proceaaora. 

The  weakness  of  IDEF,  include: 

1.  The  external  entities  are  not  explicitly  represented,  and  thus  the  interaction  of  the  system  with  external 
entities  is  only  represented  by  the  mputs,  outputs,  controls,  and  mechanism  of  the  system. 

2.  Boxes  in  IDEF,  are  forced  to  be  placed  as  a  itaircast  pattern  to  tiiow  the  dominance  among  them. 
However,  there  are  situations  where  several  functions  may  have  the  aame  dominance.  The  author  of  a 
IDEF,  diagram  still  has  to  lay  out  these  functions  as  if  they  were  different  in  their  dominance. 

3.  The  glossary  of  IDEF,  is  a  simple  description  of  the  olgects  need  in  the  diagram.  It  cannot  represent 

additional  attributes  of  the  objects  or  relationships  of  the  oljects  with  other  d^ects.  A  more  powerful 
r^iository  is  needed  to  integrate  IDEF,  diagram  %vitb  IDEF|,  diagram,  and  moth  other  tools  used  in 

the  process. 

4.  INPUT,  OUTPUT,  MECHANISM,  and  CCN^TTROL  are  terms  used  to  describe  bow  things  (i.e.,  data  and 
materials)  are  related  to  a  function  or  activity  under  study.  An  ouqiut  of  a  function  can  be  ua^  as  an  input 
or  control  of  another  fiactioa.  Controls  are  usually  in  the  form  of  information.  It  k  not  very  aasy  for 
IDEF,  users  to  determine  the  role  of  a  thing  that  interacts  with  the  fimetioo.  It  may  have  to  be  interpraied 
by  the  user,  who  could  easily  make  miftakea. 
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Fifure  7.  Mappbf  Betweea  IDEF,  kad  Rea]*<ime  DFD 
Figures  7  aod  I  Ohistnue  the  laipptnf*  between  IDEF,  dufranif  end  retl-fime  CASE  tools 
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■ 


Figure  8.  Constnict  Mapping  Between  IDEF,  and  a  Real-time  DFD  with  a  Rqwatoiy 

The  major  weakness  of  IDEF,,  iqipeare  to  be  that  it  would  be  injq>propiiate  as  a  c(mcq>tual  data  modeling  tool, 
and  also  that  the  graphical  notations  seem  unnecessarily  conq>lex.  For  exan^tles,  the  ideotifier-dq)endent  and 
ideotifier'indq)eodent  entities  have  difTeient  slu^.  However,  whether  an  entity  is  identifier  dq>eadeot  or 
indq>eadait  is  mainly  a  logical  or  jAysical  database  design  decisioo.  Tie  distinctioa  between  identifying  and 
non-identifying  relationships  is  of  the  same  nature.  At  the  conceptual  data  modelling  level,  there  is  no  n^  to 
make  such  distinctions.  The  cardinalities  of  qMcific  connection  relationship  and  non-q>ecific  relationship  can  be 
rqiresented  by  a  line  connecting  two  entities  augmented  by  a  pair  of  numbers  (rq>r6senting  minimum  and 
maximum)  or  symbols  attached  to  tiie  connecting  entities.  The  notations  of  non-q>ecific  relationship  and  qwcific 
relationship  (with  four  possible  cardinalities)  can  be  reduced  to  just  one  concise  notation.  This  would  make 
learning  and  applying  IDEF,,  much  easier. 

The  entity  relationship  model  is  an  end-user  oriented  data  modeling  technique  tiut  is  widely  siqtpofted  in  existing 
COTS  CASE  tools.  There  are  several  variations  of  ER  diagramming  notations.  ER  mo^  is  a  conceptual  data 
modeling  technique.  The  process  of  converting  an  ER  diagram  to  a  logical  or  physical  database  schema  can  be 
conqniter  aided.  For  BCA/FEA,  in  which  the  primary  users  are  from  the  busiiiess  fimctional  areas,  die  data 
modeling  technique  should  be  kqit  at  as  high  a  level  as  possible.  If  data  modeling  is  required  as  part  of 
BCA/FEA,  we  minimum  use  of  IDEFb  (the  use  IDEFb  at  die  entity-witb  key  attribute  level  only). 

We  believe,  however,  that  data  modeling  diould  be  a  part  of  BCA/FEA,  because  understanding  the  data  structures 
of  a  function  could  hdp  the  design  and  redesign  of  business  processes.  Many  information  systems  that  support 
existing  business  fractions  do  not  diare  data;  thus  many  redundant  business  processes  have  bera  created  to  reenter 
and  revalidate  data  already  in  the  system.  In  die  BCA/FEA  stage,  a  data  model  may  help  business  managers 
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redesign  the  business  processes  according  to  a  shared  database  concq>t.  Many  duplications  or  inefficiencies  of 
existing  business  processes  could  then  be  eliminated. 

IDEF,.  uses  a  set  of  terminologies  that  are  uncommon  to  the  database  design  community.  Users  may  be  confused 
if  ID£F|^  is  tised  at  the  attribute-level,  unless  they  are  properiy  trained  in  normalization  theory.  Currently,  there 
is  no  repository  concqtt  in  IDEF  techniques.  Objects  (e.g.,  activities,  inputs,  and  ouqnits)  are  defined  in  a 
glossary  that  cqrture  only  limited  attributes  of  the  objects.  Structural  relationships  among  otgects  are  not 
captured.  The  integration  of  IDEF  suite  of  methods  could  be  achieved  by  using  a  repository  system  that  can 
support  the  data  integration  amcmg  tools  that  support  IDEF  rrrethods  and  related  tools  for  BCA/FEA.  Currently, 
IDEF  does  not  provide  a  predefined  set  of  attributes  and  relatimtships  for  further  description  of  the  characteristics 
of  IDEF  objects  and  their  relationships  to  other  objects.  Due  to  this  deficiency,  if  IDEF  has  to  be  used  in 
BCA/FEA,  a  meta-nwdel  of  the  IDEF  has  to  be  defined  to  serve  as  a  foundation  for  implementing  rq>o8itory- 
based  IDEF  tools  [Chen  and  Sibley,  1991].  Inqrortant  information  requited  for  BCA/FEA  should  be  defined  in 
the  meta-model.  The  following  are  some  suggestions: 

1.  Cost  aird  resource  utilization  data  could  be  associated  with  MECHANISM.  These  include  volume, 
frequency,  unit  cost,  etc. 

2.  Performance  data  could  associated  with  INPUTS,  OUTPUTS,  and  PROCESSES.  Exanq>les  of  performance 
data  include  response  time,  throughput,  etc. 

3.  Things  can  be  categorized  into  data  and  non-data  objects  that  ink  data  objects  used  as  inputs,  controk,  or 
outputs  of  processes  in  IDEF,  with  IDEF,,  diagrams  or  Iwith  other  data  structures  descriptions. 

6.  Using  roEF  for  Business  Process  Modeling 

In  discussing  the  ISDOS  project  in  retrospect,  one  author  has  said  that  there  was  major  industrial  apathy  due  to  a 
lack  of  the  use  of  its  PSL/PSA  generated  documents  for  urq>lemeoting  the  target  system  [Sibley,  1986]  —  thus  the 
users  saw  it  only  as  a  complicated  documentation  device.  If  the  only  purpose  of  using  IDEF  in  BCA/FEA  is  to 
document  the  business  process  model,  the  potoitial  benefits  of  using  it  will  be  limited.  We  believe  that  IDEF  or 
its  altenutive  techniques  should  be  used  for  continuous  business  improvement  and  for  downstream  systems 
development  activities.  If  a  technique  or  tool  is  used  only  for  documentation,  no  one  is  likely  to  have  a  vested 
interest  in  keeping  the  model  up-to-date.  The  effort  spent  in  building  the  business  process  ttKxlels  may  be  wasted. 

The  business  expertise  embedded  in  business  models  is  a  valuable  asset  that  should  be  exploited  by  functional  area 
users  and  managers  with  the  assistant  of  business  analyst.  Once  the  model  has  been  developed,  it  could  be  used  to 
by  functional  area  users  and  managers  to: 

1.  support  continuous  business  inq)rovement  based  on  the  performance  criteria  established  in  the  model, 

2.  assist  the  business  reengineering  process  in  making  structural  changes, 

3.  navigate  and  explore  the  nx>del  in  order  to  understand  the  goals  and  objectives  of  the  organization, 

4.  guide  the  development  of  IS  models  to  ensure  dut  the  IS  are  aligned  with  business  objectives. 

5.  perpetuate  a  cotnnKm  mental  model  of  the  business. 

6.  form  the  basis  for  delivering  information  in  the  buaness  context 

Business  process  nxxlels  should  be  integrated  with  information  systems  models  because  many  critical  business 
fimctions  are  supported  by  IS.  An  integrated  model  should  be  used  not  only  for  the  design/redesign  of  business 
and  its  information  systems,  but  also  the  users  to  deliver  the  information  [Chen,  Nunamaker,  and  Weber,  1989; 
Chen,  Liou,  and  Weber,  1S>92]. 


7.  Cgnglusiflns 

Training  is  one  of  the  inqrortant  factor  in  successfully  irsplementing  a  methodology.  It  is  particularly  critical  m 
iaq>lemaiting  IDEF  as  a  front  end  modeling  technique  to  support  business  engineering/reengineering  and  to 
fiicilitate  BCA/FEA  because  these  processes  ate  driven  by  end  users  and  tnaiutgers.  They  are  usually  not  funiliar 
with  the  systematic  approach  in  analyzing  and  designing  business  systems  and  information  systems.  However, 
their  involvement  is  politically  smart.  It  is  the  only  way  to  c^ture  the  information  and  knowledge  about  the 
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businesses  and  dieir  operations.  By  tq>pin{  into  front-line  users’  and  managers’  expertise  and  creativity  about 
how  they  may  inqnove  dieir  work  processes,  we  will  have  a  better  chance  to  introduce  dramatic  inqwovements  in 
dte  processes.  Training  on  IDEF  in  d>e  FEA  diould  be  given  to  both  business  analysts  and  user/managers  of 
various  agencies.  Real-time  training  diould  be  given  no  friat  people  with  die  training  can  apply  the  techniques, 
methods,  and  tools  in  dieir  jobs. 

The  BCA/FEA  is  a  change  process.  It  changes  the  way  we  ftint  about  systems  investment  and  develc^ment 
processes  and  the  users’  and  managers'  roles  in  diese  process.  It  is  a  change  of  mind  set  instead  of  a  change  of 
notations.  Therefore,  it  is  more  important  to  educate  the  agencies  about  the  underlying  principles  of  QM  first, 
dien  familiarize  diem  with  BCA/F^  processes.  IDEF  and  other  related  techniques,  methods,  and  tools  are 
important  mechanisms  to  cany  out  the  vision  of  CIM,  but  they  diould  be  introduced  after  die  CIM  principles  and 
process  have  been  fully  understood. 
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Framework  for  Performing  Business  Case  Analysis  (BCA) 
in  Office  of  the  Secretary  of  Defense  (OSD)  Staff  Offices 


I.  Preparation 

A.  Obtain  Upper  Management  Support  for  BCA  project. 

1.  Brief  upper  management  on  the  BCA  procedures  to  be  used. 

2.  Obtain  pointsof  contact  (POCs)  to  support  the  analysis  team  in 
the  following  categories:  Functional  POCs,  Information  Systems 
(including  office  automation)  POCs,  and  Organizational  POCs. 

B.  Obtain  Mission  and  Functions  Statement  of  the  organization(s)  understudy. 

1.  Determine  external  interfaces  (customers,  suppliers,  and  competitors). 

2.  Determine  internal  interfaces  (customers,  suppliers,  and  competitors). 

3.  Determine  categories  and  types  of  products  and  services. 

C.  Obtain  Organization  Chart  of  orqanization(s)  under  study. 

1 .  Determine  manpower  authorizations  by  position  and  grade/rank. 

2.  Determine  personnel  on-board  and  in-hire  by  position  and  grade/rank. 

3.  Determine  average  fully-burdened  rate  for  each  grade/rank. 

D.  Obtain  Inventory  of  current  and  on-order  office  equipment  and  facilities. 

1 .  Determine  authorized  and  on-hand  equipment  and  facilities. 

2.  Determine  age  and  price  (new)  of  each  piece  of  equipment. 

3.  Develop  depreciated  value  of  equipment. 

4.  Develop  replacement  schedule  for  existing  equipment. 

E.  Obtain  Operating  Budgets  of  organization(s)  for  previous  and  current  year. 

1.  identify  all  expenditure  object  classes  and  past/present  budgets. 

2.  Identify  other  sources  of  organization  funding  or  support,  if  any. 

3.  Identify  budget  short-fall  or  surplus  by  object  class,  if  applicable. 

II.  Abreviated  BCA 

A.  Conduct  Interviews  with  functional,  information  systems,  and  organizational 
POCs  to  identify  functions,  information  systems  (including  office  automation), 
and  organizations,  and  their  suspected  cost  drivers.  For  each  cost  driver: 

1 .  Ascertain  time  spent  on  cost  driver  per  unit  time  (day/week/month/year). 

2.  Ascertain  reason  for  inefficiency  or  ineffectiveness. 

3.  Ascertain  suggested  method  for  improvement. 

4.  Ascertain  estimated  savings  (time  or  $)  per  unit  time. 

B.  Estiniate  Workload  Factors  for  current  year  and  planning  years. 

1.  identify  all  types  of  work  performed  and  measures  of  effectiveness. 

2.  Identify  sources  of  workload  information. 

3.  Identi^  quantity  and  quality  of  each  type  of  work 

C.  Perform  High-Level  IDEFO  Process  "As-ls"  iVlodellinq  of  organization. 

1.  identify  macro-level  inputs,outputs,  controls,  and  me^anismsvia  POCs. 

2.  Prepare  "As-ls"  AO  Context  Model  plus  Level  1,  at  a  minimum. 

(If  time  permits,  "As-ls"  model  should  be  decomposed  to  a  level  that 
will  identify  specific  business  areas  believed  to  contain  potential  for 
improvement  either  from  process  re-engineering  or  OA.) 

3.  Validate  macro-level  inputs,  outputs,  controls,  and  mechanisms  via  POCs. 


D.  Map  Baseline  Costs  to  the  IDA  template. 

1.  Management  and  Suppprt  Costs. 

2.  Operations  Costs. 

[1.  Personnel  and  Overhead  Costs. 

a.  Map  actual  expenditures  (if  available)  and  I  or  current  year  budgets 
into  the  current  FY  of  the  IDA  template. 

b.  Estimate  outyear  costs  using  current  office  automation  support  and 
relative  workload  factor  forremainig  years  in  the  planning  horizon. 

2.  OA  Equipmen  tand  Facilities. 

a.  Estima  te  outyear  equipment  purchases  based  on  obsolescence 
schedule  from  Section  I.C above.  Consider  relative  workload  factor 
for  each  FY.J 

E.  Perform  High-Level  IDEFO  Process  "To-Be"  Modelling  of  organization. 

1.  Identify  opportunities  to  reduce  costs  and  improve  performance  based  on 
suspected  cost  drivers  identified  above  via  POCs. 

2.  Prepare  "To-Be"  AO  Context  Model  plus  Level  1,  at  a  minimum. 

("To-Be"  model  should  also  be  decomposed  to  the  same  level  as  the 
"As-ls"  model.  Note:  If  current  business  processes  are  sound  and  OA 
technology  alone  will  provide  increased  productivity  or  cost  savings,  the 
"To-Be"  model  will  not  differ  from  the  "As-ls"  model.) 

3.  Validate  macro-level  inputs,  outputs,  controls,  and  mechanisms  via  POCs. 

F.  Map  Alternative  Costs  to  the  IDA  template. 

1  Management  and  Support  Costs. 

2.  Operations  Costs. 

[1.  Personnel  and  overhead  costs. 

a.  Estimate  impact  of  process  re-engineering  and  /  or  OA  technology 
on  baseline  costs  for  each  FY. 

b.  Consider  relative  workload  for  each  FY. 

c.  Map  high  and  low  estimated  costs  to  the  IDA  template. 

2.  OA  Equipment 

a.  Estimate  high  and  low  OA  equipment  costs  supporting  the 
alternatives  for  each  FY.  Consider  relative  workload  factors.] 

G.  Perform  Risk  Adjusted  Discounted  Cash  Flow  (RADCF)  using  IDA  model. 

H.  Determine  risk  acceptablity  and  refine  estimates  if  necessary. 

I.  Perform  sensitivity  analysis  on  alternatives  and  rerun  RADCF  model. 

J.  Document  results  and  brief  management. 

K.  Iterate  at  next  lower  level  of  detail,  if  necessary. 


SUPPLEMENTARY 


INFORMATON 


151. 


COMMANO.  CONTROL. 
COMMUNICATION 
ANO  INTELLIGENCE 


OFFICE  OF  THE  ASSISTANT  SECRETARY  OF  DEFENSE 
6000  DEFENSE  PENTAGON 
WASHINGTON,  D.C.  20301-6000 


;  \99A 

ERRATA  Mi  9(701 


MEMORANDUM  FOR  DEFENSE  TECHNICAL  INFORMATION  CENTER 

ATTN:  DATA  BASE  SUPPORT,  WILLIAM  BUSH 

SUBJECT:  Corporate  Information  Management  Bibliography- 

Limitations 


We  have  reviewed  the  documents  under  our  purview  and 
currently  limited  for  distribution  through  DTIC.  We  have 
determined  that  the  limitations  on  the  following  documents 
can  be  changed  to  Category  A,  Approved  for  Public  Release, 
Distribution  Unlimited: 

ACCESSION  NUMBER:  M200225 

B171442. 

M200146 
M200149 
rM2Q0146LV 
M200107L 
B164404 
B166990L 
M200140 

The  following  documents  will  remain  under  the  current 
Category  E  distribution  limitations: 

• 

ACCESSION  NUMBER:  B174459L 

M200175L 

M200176L 


Gr 

Ki0.3>,a)Qa/£ 


Michael  S ,  Yoemans 

Director,  Functional  Process  Improvement 


o 


cc:  Frank  FitzMaurice,  DTIC 


ERRATA ' 


